The central processing unit (CPU) or processor lies at the heart of all modern computing systems. The processor executes instructions of a computer program and thus enables the computer to perform useful work. CPUs are prevalent in all forms of digital devices in modern life and not just dedicated computing machines such as personal computers, laptops and PDAs. Modem microprocessors appear in everything from automobiles to washing machines to children's toys.
A problem arises in that program code which is executable by one type of processor often cannot be executed in any other type of processor. Firstly, each type of processor has its own unique Instruction Set Architecture (ISA). Secondly, processors often have unique hardware features which are not present on other types of processor. Hence, the field of program code conversion has evolved to automatically convert program code written for one type of processor into code which is executable instead by another type of processor, or to optimise an old, inefficient piece of code into a newer, faster version for the same type of processor. That is, in both embedded and non-embedded CPUs, there are predominant ISAs for which large bodies of software already exist that could be “accelerated” for performance or “translated” to other processors that present better cost/performance benefits. One also finds dominant CPU architectures that are locked in time to their ISA and cannot evolve in performance or market reach. This problem applies at all levels of the electronics industry, from stand-alone pocket-sized devices right through to massive networks having tens or hundreds of powerful computers.
As background information in this field of program code conversion, PCT publications WO2000/22521 entitled “Program Code Conversion”, WO2004/095264 entitled “Method and Apparatus for Performing Interpreter Optimizations during Program Code Conversion”, WO2004/097631 entitled “Improved Architecture for Generating Intermediate Representations for Program Code Conversion”, WO2005/006106 entitled “Method and Apparatus for Performing Adjustable Precision Exception Handling”, and WO2006/103395 entitled “Method and Apparatus for Precise Handling of Exceptions During Program Code Conversion”, which are all incorporated herein by reference, disclose methods and apparatus to facilitate program code conversion capabilities as may be employed in the example embodiments discussed herein.
Most modern processors include a set of registers as a type of fast-access memory. The processor uses the registers to hold temporary values while executing a sequence of instructions in a computer program. The processor hardware contains a limited number of these registers and, in use, execution of the program can readily fill all of the available registers with temporary data values. This leads to competition for the available registers as the processor moves from one section of code to another, because each section of code will generate temporary values and will need to make use of the registers in the processor to store those temporary data values.
In response to this difficulty, processors have been developed with a register window architecture. For example, register window architectures based on the Berkeley RISC design of the early 1990s provide a large set of hardware registers (the register file) and allow only a small subset of these registers (the register window) to be accessed by the current section of code. The other registers in the register file lying outside the current position of the register window are not accessible by the current section of the computer program. For example, only eight registers are visible at any one time from a register file of sixty-four registers in total. When the processor moves from one section of code to another, such as when a procedure call is performed, then the register window shifts position in the register file and exposes a different subset of the registers for the new section of code. These movements are generally classified as either causing a SAVE type movement where the register window moves to a previously unused position to present a clean set of hardware registers to the executing subject code, or else a RESTORE type movement which shifts the register window back toward a previously exposed position and thus reveals a set of previously used registers to the executing code to thereby restore access to the data values held in those registers. Eventually, however, the finite number of hardware registers in the register file will be exhausted, depending upon the number of procedure call levels invoked by executing the program. Here, a SPILL operation is performed whereby the data values in the registers are moved to a safe location such as in second-tier memory outside the processor. Later, a FILL operation moves those data values back into the hardware registers so that processor can continue execution of the relevant section of code.
This register window architecture is intended to allow the computing system to execute faster, especially where the processor frequently moves from one section of code to another and then returns back to the first section (i.e. performs procedure calls), by avoiding the costly and time-consuming register spill and fill operations for large parts of the computer program.
This register window architecture has been adopted by processors such as the SPARC, the AMD29000 and the Intel i960 on a large commercial scale. Hence, a large body of code has already been written to execute only on these architectures and cannot be run by any other type of processor.
Of these commercial processors, the SPARC is particularly prevalent. Further background information about the SPARC register window architecture is found, for example, in SPARC Architecture Manual, Version 8, Section 4.1, “Registers” and SPARC Architecture Manual, Version 9, Section 5.1, “Registers”, published by SPARC International Inc of San Jose, Calif., the disclosure of which is incorporated herein by reference.
As an example, FIG. 1 illustrates the use of register windows in a v9 SPARC architecture of the related art. The v9 SPARC architecture provides a plurality of control/status registers, and a large number of general purpose (“r”) registers. The general purpose registers include eight permanently visible global registers (and a further eight global alternates), and a moveable 24-register window divided into eight “in” registers, eight “local” registers and eight “out” registers. The current window into the total register file is given by a Current Window Pointer (CWP) held in one of the control/status registers. The CWP is incremented each time a “restore” instruction is executed, and is decremented for a “save” instruction or when a trap occurs. In this example, the 24-register window partially overlaps with adjacent windows positions, such that the eight “out” registers of one window position overlap with the eight “in” registers of an adjacent window position, whilst the local registers are unique to each window position. That is, the “out” registers of window position CWP+1 are also addressable as the “in” registers of the current window CWP. Also, the “out” registers of the current window CWP are equivalent to the “in” registers of the next window CWP-1. The v9 SPARC architecture supports from a minimum of three to a maximum of thirty-two window positions, depending on the specific hardware implementation. Hence, together with the permanently visible global registers, the v9 SPARC architecture requires 64 to 528 general purpose hardware registers (8 global registers, 8 alternate globals, and 16 registers for each window position).
FIG. 2 illustrates the circular nature of the windowed register file in the example v9 SPARC architecture. The hardware registers are finite in number and in this example there are 128 windowed hardware registers corresponding to eight register window positions. FIG. 2 shows window position W0 as the current window (CWP=0). If a procedure using the current window position W0 executes a RESTORE, then window position W7 will become the current window (CWP=+1). If the procedure at position W0 instead executes a SAVE, then window position W1 becomes the current window. A window overflow trap occurs when all of the register window positions have been consumed, i.e. because those registers already contain valid data from executing previous the sections of program code and should not be overwritten. In the example v9 architecture, window overflow is detected using a CANSAVE control/status register linked to the CWP. At this point, the contents of the registers are spilled to a slower-access area of memory, such as an execution stack in the main subject memory 8, in order to allow execution to continue without overwriting valid data stored in the register file. When the program eventually RESTOREs to the point where the original register values become needed again, a fill operation fills the register values from the stack back into the hardware registers of the register file. Here, a window underflow trap prevents an invalid restore movement of the register window, with reference to a CANRESTORE control/status register.
In this example, the original program code (here called “subject code”) relies on a particular type of subject hardware having a register window architecture. However, in the field of program code conversion of the present invention, the subject code is instead converted into target code and executed by a target computing system. That is, it is desired to replace an older subject computer system based on the register window architecture instead with a newer target computer system, but still have the target computer system support the register window architecture of the subject computing system.
An aim of the present invention is to provide a computing system which is adapted to support a register window architecture. Exemplary embodiments aim to adapt a computer system to support a foreign, non-native, register window architecture.